Potentially a topic for debate (or not) and I've searched and searched but not found anything. I code quite a lot of HTML emails (for my sins) and am surprised that this debate has only just come up but is there any way of determining where the "fold" would be in an HTML email?
I've thought about this quite a bit and of course it depends on lots of things such as:
How the user has setup their viewing panes (if using Outlook)
Screen resolution
What email client they are using
So I may have really answered my own question but I hope this is open for debate. Is there any "best practice" guidelines? I.e. maximum width (I try and keep emails below 600 and below) and of course the things I listed above. I've looked at the usual sites, MailChimp, Campaign Monitor etc to no avail!
I would be interested to hear your thoughts/comments/suggestions.
Thanks
Kiz
For HTML documents, you'd need to look into JavaScript code to check window dimensions. Alas, most e-mail clients disallow JS in incoming mail, so this will be extremely unreliable.
Aside from this, I don't think there's a way to do this: I've seen so many configurations that I think any size is possible.
Related
Apologies in advance for code overkill. I don't have any idea where the problem lies, so I'm just going to have to paste in the whole thing. I don't think what I've been trying to build is particularly complex- but I AM now particularly out of my depth. I got misled when the previews at Email On Acid looked fine all along as I was busy editing away, copy pasting code and viewing the result as I went along. But when I sent the email to my Android device there wasn't any stacking for the small screen. All three columns are rigidly there and the text has not adapted.
I've realised belatedly after researching this as much as I could and reading an excellent article on table-based spongy/fluid design by Nicole of Merlin of Email Wizardry that media queries are not good. The template I used in EOA has them unfortunately. And now I need to repair my email newsletter before I get lynched by the committee of the non-profit I am carrying this out for gratis.
I could give up trying to build it to spec and head over to Mosaico to make something generic, but this email newsletter at least needs to contain internal links!
Could you have a squizz at my code and give even a general pointer as to where I might have gone wrong and what to do to fix it?
Thanking you in advance. Code to follow by attached text file:
...actually the code won't even paste in here: 'formatted wrongly' I can't find any option that will allow me to communicate the code to other users here. Tried getting the content temporarily hosted, but they had a character limit my project exceeded. Could attach text file if I could find a way. Apologies for the noob questions! But really want to complete this!
I searched for this question-- both in Google and Stackoverflow-- but couldn't find what I wanted.
Now, whenever I see the source code of a website, like Facebook or Google, their HTML code is spanned in just one line? Why do they do it? What is the significance of doing it? Do I need to do it for small websites as well, say maybe a school website?
The main Google page server millions of page views every hour. If it's one byte longer, that means gigabytes of additional data are transferred over the Internet every day.
That's why big sites with lots of traffic really squeeze every bit out of their HTML code. For small sites, this isn't really an issue.
Here'a a StackOverflow answer with a lot of reasons why web sites use "bad practices" in general: Why do big sites use 'bad practices'?
As others have said, though, the "one big line" issue is usually motivated by both performance considerations and obfuscation.
Frankly, unless you're serving hundreds (thousands?) of page load per minute, I wouldn't worry about that.
As said by Aaron Digulla, its used to keep byte size down.
Its also used to remove whitespaces (which can cause errors in php&js), comments and also to keep pesky people from trying to steal code. In minified form, its harder to read and therefore harder to copy.
We called that "minification" (remove unnecessary information from the code (White spaces, comments etc.) ). not only for html, you can do that it for javascript, css etc as well. Minification improves overall performance of the application.
Wikipedia explanation:
http://en.wikipedia.org/wiki/Minification_%28programming%29
You can apply that for small web sites as well. There are tools available for that and it is a best practice as well.
Part of my job involves turning psd designs into html to be emailed out for email campaigns. In the past I've always gone through and converted everything to a suitable html element where possible but I'm now questioning whether there's any point to it?
Is okay just to use one giant image? I only ask because it seems using html elements is only really important if a) I want the information in the email to get to the client if images are blocked and b) for SEO.. yet search engines won't be indexing my code since it's all going through email.
If I'm pretty confident that the clients I'll be mailing won't have the images blocked, is it okay just to treat the entire email body as an <img />?
Thanks
I guess it would be okay, but I wouldn't recommend it. Here are a few reasons why:
The readers won't be able to select and copy any of the content in the email, which in my opinion is really annoying.
You will not be able to have links in your email, the only thing you can link is the entire image.
If they do have images disabled, which i believe is fairly common, the wouldn't see a thing without downloading the image.
Increased email size due to the large image, which for mobile devices is a pain.
An image will not adapt to the window/display size. Text/HTML-based mails can at least break row if the content doesn't fit, to make it more readable.
And the list goes on. The other answers point out a number of additional reasons as well.
I don’t know that there is any definitive answer to this question, but here is my take on it:
I think it’s a good idea to convert certain elements to text so that they can be copied or manipulated. If you have a phone number, you may want that to be readable so that anyone with an automated dialer can click and complete the call. Certain email programs might automatically convert an address to a link to the map. Those features won’t work if any of these elements are flattened into the jpg.
For those mobile email clients that will not render the image on the screen (either because it’s just showing the preview or hasn’t yet downloaded the content) it’s useful to see some of the alternate text (and body content) before viewing the full image.
I know you said that you are sure your clients won’t have images blocked, but you can’t really rely on that. A well-meaning administrator who makes a change to the firewall could accidentally block all incoming images to the entire domain and your email will be worthless.
Lastly, an HTML email with one line of code to load an image has a high possibility of being flagged as spam.
I hope this helps!
What about bandwidth concerns, for users viewing your email on a mobile device? If it's a large image, do you want to blow out their data caps?
Or users using assistive technology, for visually-impaired people. Such as a screenreader(text to speech).The real text is helpful for scenarios like that.
Trying to see if there are any negatives to adding HTML comments to my html emails?
Any feedback is great.
Thanks
I don't think so. I've made several professional e-mail templates for Outlook that contained a little notice in the comments. I've never had any problems with that.
I even had fun to see that I could find an e-mail sent by a customer, because Google had indexed it, including the comment. :D
It does increase the size of the e-mail a little, so use with care.
None, unless the number of comments are too many that they affect DOM parsing by the browser/email client and congest network traffic.
Unless you're revealing secrets of your network, I don't see anything wrong with it. Allot of systems have comments to highlight template system areas.
Two drawbacks :
It makes the e-mail bigger. You should consider it if time or bandwidth is an issue, say if you are going to send thousands of e-mails.
It means your e-mail is in HTML, which is to be avoided if possible at all.
It should be fine, but I would be careful with any sort of emails with html content. Html in email is particularly tricky because the clients (aol, outlook, gmail, thunderbird, etc) can display the results quite differently. A quick google search brought me to emailonacid.com, an email testing/deliverability tool which might be useful if you want to be thorough.
One thing I ran into recently was that comments in email HTML should be avoided when nesting around MSO code (used for visibility/layout issues with MS products). I had an image refuse to load in Outlook.com because the MSO text was located in-between two of my comments. The syntax seemed to confuse Outlook in particular. Drove me bats. Then I took the comments out, wham -- the image displayed, problem solved.
I read somewhere that when creating a HTML email, you should use the table-based layout. You should not care about creating tableless css based layout. Is that true?
I have to create a newsletter layout for my company, but I dont feel confortable writing 3 nested tables.
If you want your HTML-email to look good in most email clients, you should write your HTML as it still was 1999 :)
I'd highly recommend paying a visit to the Email Standards Project website. It lists almost every major email client (both standalone and web-based) on the market and outlines how much HTML support is built into each one.
Also check out Campaign Monitor's email design guidelines for some practical guides for proper HTML email building -- including, sadly yes, "use tables."
This is probably more based on the reality of email client rendering (which is terrible) than anything else. Technically it's almost certainly wrong, but pragmatically it might be the best advice. Truppo touches on this.
I would love a world where no one expected HTML to be used where plain text would do, but that is not the situation. If your job is to come up with HTML that will not embarrass you when your subscribers try to view it in their favorite email clients (applications or web based email), it is hard to stick with semantic markup and CSS.
Take what I am saying with a grain of salt because I have only done this as a learning exercise and not professionally. Based on an article I had bookmarked and further links I found in that article, the following pages seem to have a good discussion of the real issues involved in sending HTML email.
http://www.sitepoint.com/article/code-html-email-newsletters/
http://www.sitepoint.com/article/principles-beautiful-html-email/
http://www.sitepoint.com/article/designers-guide-html-email/
Given the issues involved, using tables for layout makes practical sense.
There's certainly no standard that mandates it, and in fact, best practices dictate that tables should not be used for layout (except in the case of laying out tabular data).
There is an argument to be made for using tables in presentation, as there's no guarantee the plethora of desktop and web-based email clients will render CSS-based presentation properly... However, I wouldn't say that's an argument in-and-of itself.
I won't advise you to do it, but you had probably hear this because a lot of email reader supports only a few html and css.
They often don't bundle a full html/css parser, and in the past table was much used to do layouts..
You may want to look at this, although this is specifically about the Oulook html/css subset support described:
http://msdn.microsoft.com/en-us/library/aa338201.aspx
The reason tables are used is two-fold:
HTML e-mail can be rendered in a vast array of clients with widely differing abilities. It's like trying to design a website for every browser, then multiply it by 10.
Quite a few web e-mail clients play havoc with CSS layout.
I found outlook having problem with div based layouts.
We've been doing some tests with customers on how newsletters look on their computer and found that a majority is using a layout in Outlook or in Mail that shows a width of only about 45 characters. They don't bother to double-click to open the email in a new window or scroll around.
The emails with some content other than a logo and text that appeared somewhat better were the ones with only one big GIF...
+1 on Campaign Monitor's advice. I've also seen a lot of great content from Emma. In my experience, the simpler you can make an email newsletter template, the better. This is doubly-true in a world where an increasing percentage of users are reading your message on a mobile device with a small screen.
In the past it was common to use tables for page layout, and many people who create pages are still more comfortable doing it this way.
As James says, best practice is to use CSS positioning facilities for page layout except when it actually is tabular data; but personally I often find it hard to get the effects I want with CSS.